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United States Patent and Trademark Office 


This is in response to the appeal brief filed 3/13/2006 appealing from the Office action mailed 
10/3/2005. 
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(i) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief, 
(z) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial 
proceedings which will directly affect or be directly affected by or have a bearing on the 
Board's decision in the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection contained 
in the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is 
correct. 
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(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 


(8) Evidence 

Relied Upon 


5719942 

Aldred et al. 

3-1995 

5680549 

Raynak et al. 

12-1994 

6005568 

Simonoff et al. 

9-1997 

5423042 

Jalili et al. 

10-1992 


(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 

Claim Rejections - 35 USC § 103 
i> The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art 
are such that the subject matter as a whole would have been obvious at the time the invention was made to a 
person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be 
negatived by the manner in which the invention was made. 


2> Claims I, 12 and 20 are rejected under 35 U.S.C § 103(a) as being unpatentable over 
Aldred et al, U.S Patent No. 5.719.942 ["Aldred"], in view of Raynak et al, U.S Patent No. 
5.680.549 ["Raynak"]. 
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3> Aldred discloses a method of communicating function calls or event notification 
between two applications [column 12 «lines 44'*5i»], said method comprising: 

a first application launching a second application wherein the launching of the second 
application includes the first application passing parameters to the second application 
[column 5 «lines 5i'63» | column 6 «lines 39-49» | column 7 «lines 33-62» | column 12 «lines 
57-6i»column 11 «lines 27-39» | column 29 «lines 8-i9» | column 36 «lines 3-52» where:. Aldred 
clearly discloses a "launch_app" function that is "issued by an application", the launch_app 
having parameters that are "given to the launched application"]. 

Aldred does not expressly disclose storing the port numbers in a memory accessible to 
the second application nor does he disclose that the parameters passed in the launch_app are 
port numbers. 

4> Aldred does disclose storing a customization file in a repository, the file containing 
configuration and start-up options as well as information relating to physical links [column 
10 «lines 37''50» : LAKES.INI file] but does not explicitly disclose storing the port numbers. 
It is implicit to Aldred that the port numbers are stored in a memory accessible to both 
applications because Aldred discloses the LAKES.INI file contains configuration, start-up, 
and physical link information. Ports are related to configuration and physical link 
information of the applications. Furthermore, applications are able to alter ports and channels 
after having been initially established [column 8 «lines 49'55» | column 12 «lines 36-42»]. 
Therefore, the port and channel information must be stored in a place, such as the 
LAKES.INI file associated with the applications, that can be accessed by the applications in a 
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manner that enables them to modify them as disclosed by Aldred. One would have been 
motivated to perform such an implementation as storing connection (port) information for 
applications is expected and well known in the art as it allows the applications to maintain 
connection flexibility. 

5> While Aldred does not expressly disclose passing ports as parameters in the 
launch_app function. However, such functionality is suggested by Aldred's disclosure that a 
sending application is responsible for establishing channels and the channels being defined 
by ports [column 6 «lines i7-32»]. Further, Aldred discloses that after an application has been 
launched, the launched application's handle is returned to the launching application [column 
II «lines 33-34»] and there is return data to the launched application [column 11 «lines 36'38»]. 
Such functionality suggests that a channel has already been established between the launched 
and launching application. 

Further, Raynak is directed towards a system for enabling a first application to invoke 
a second application. The first application passes to the second application port and 
connection information as part of launching the second application as command-line 
parameters [Figure 4 | column i «lines ii-24» | column 6 «lines 32-57»]. Examiner notes that 
the second application uses the port information to take over the connection from the first 
application, and thus is not completely analogous to the second application in Aldred. 
However, the functionality relied upon in Raynak is that port and other connection 
information is transmitted by a launching application to a launched application. It would be 
obvious to one of ordinary skill in the art to incorporate Raynak's command-line parameters 


Application/Control Number: 09/963,435 Page 6 

Art Unit: 2152 

into Aldred's launch_app parameters to enable the launched application. As mentioned, 
Aldred's disclosure of handle and return data being transmitted between the launched 
application and the launching application in response to the launch_app function suggests 
that a connection is established between the applications. Thus, Raynak's command-line 
parameters teaches that Aldred's launch_app parameters could include port information. 

6> As claim 12 is merely an article that performs the steps of the method of claim i, it 
does not teach of further define over the limitations of claim i. Therefore, claim 12 is rejected 
for the same reasons set forth in claim i, supra . 

7> As to claim 20, Aldred discloses a device, comprising: 
a processor [column 3 «lines 65-66»]; 

a memory coupled to the processor [column 3 «lines 6y6'j» \ column 4 «lines 39'43»], 
wherein the memory comprises program 
instructions configured to implement: 

the limitations of the method of claim i [see claim i, supra], 

8> Claims 2-6, 8-11, 13-17, and 19 are rejected under 35 U.S.C § 103(a) as being unpatentable 
over Aldred and Raynak, in further view of Simonoff et al, U.S Patent No. 6.005.568 
["SimonofP]. 
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9> As to claim 2, Aldred does not explicitly disclose the method comprising the second 
application connecting a TCP/IP client socket to the event port. 

io> Connecting a TCP/IP socket to a port is well known and expected in the art. For 
example, Simonoff discloses establishing a socket connection on a given port [column 8 
«lines 63'65» | column 10 «lines I3'27»]. In addition, it is well known in the art that sockets 
are commonly defined in part by a port address. Therefore, as Aldred discloses event ports as 
endpoints to the two-way communication channel, it would have been obvious to one of 
ordinary skill in the art to have reasonably inferred that TCP/IP socket functionality would 
have been included in Aldred's system. 

ii> As to claim 3, Aldred does not explicitly disclose the method comprising connecting a 
TCP/IP cUent socket to the command port, 

I2> Connecting a TCP/IP socket to a port is well known and expected in the art. For 
example, Simonoff discloses establishing a socket connection on a given port [column 8 
«lines 63'65» ] column 10 «lines i3-27»]. In addition, it is well known in the art that sockets 
are endpoints of a two-way communication link and are commonly defined in part by a port 
address. Therefore, as Aldred discloses command ports as endpoints to the two-way 
communication channel, it would have been obvious to one of ordinary skill in the art to 
have reasonably inferred that TCP/IP socket functionality would have been included in 
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Aldred's system, and specifically, that establishment of the TCP/IP socket would connect to 
both ports located on either end of the channel. 

i3> As to claim 4, Aldred does disclose storing the connection parameters of streams 
between applications [column 4 «lines 44-54» | column 7 «lines 44-62» | column 8 «line to 
column 9 «line 5»], 

It is well known in the art that sockets are endpoints of a two-way communication 
link and are commonly defined in part by a port address. Therefore, as Aldred discloses event 
ports as endpoints to the two-way communication channel, it would have been obvious to 
one of ordinary skill in the art to have reasonably inferred that TCP/IP socket functionality 
would have been included Aldred's system, and specifically, that the Aldred's stream 
connection parameters (IP address, bandwidth, ports, quality of service, etc.) would be 
applied to client sockets. 

I4> As to claim 5, Aldred discloses the method of claim 2, further comprising passing a 
function reference value through the command port connection [column 24 «lines 52-6i»]. 

I5> As to claim 6, Aldred discloses the method of claim 3, further comprising passing a 
function parameter through the command port connection [column 24 «lines 39-42» | column 
35 «line 48» to column 36 «line 65» : see for example, the "parameters" passed along with the 
launch_app function]. 
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i6> As to claim 8, Aldred discloses the method of claim 2, further comprising passing an 
event notification tag through event port connection [column 31 «line 59» to column 32 «line 
67»]. 

I7> As to claim 9, Aldred discloses the method of claim 8, further comprising checking 
the event port for an event notification tag [column 25 «lines 23-27» | column 30 «lines 48-5i» 
where; the command initiates rrionitoring for events at the port], 

i8> As to claim 10, Aldred discloses the method of claim 9, further comprising checking 
the command port in response to receiving an event notification tag [column 25 «line 53» to 
column 26 «line io»], 

I9> As to claim 11, Aldred discloses the method of claim 9, passing through the event port 
connection an event port notification tag relating to the completion of a function [column 37 
«lines i-9»]. 

20> As to claims 13-17 and 19, as they are merely articles that perform the steps of the 
method of claims 2-6 and 8, respectively, they do not teach or further define over the 
limitations of claims2-6 and 8. Therefore, claims 13-17 and 19 are rejected for the same reasons 
set forth for claims 2-6 and 8, supra . 
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2i> Claims 7 and 18 are rejected under 35 U.S.C § 103 (a) as being unpatentable over 
Aldred, Raynak and Simonoff, in further view of Jalili et al, U.S Patent No. 5.423.042 
["Jalili"]. 

22> Simonoff does disclose the method of claim 5 further comprising passing a value of 
memory location [column 36 «lines 34-37»] but does not specifically disclose storing a result 
of a function trigger by the passing of the function reference value. 


23> Jalili discloses passing a value of a memory location for storing result of a function 
trigger by the passing of the function reference value [abstract | column 10 «lines 33'48»]. It 
would have been obvious to one of ordinary skill in the art to incorporate Jalili's memory 
location for storing results of functions into SimonofP s pointer functionality to 
communicate to the second application where to store the results of a function. 

24> As claim 18 is merely an article that performs the steps of the method of claim 7, it 
does not teach of further define over the limitations of claim 7, Therefore, claim i8is rejected 
for the same reasons set forth in claim 7, supra . 


(10) Response to Argument 
1. Claims I, 12. and 20 
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Claims i, 12 and 20 stand finally rejected as being unpatentable over Aldred, in view of 
Raynak. Applicant argues that Aldred and Raynak do not teach a first application launching a 
second application, where the launching of the second application includes the first 
application passing an event and command port number to the second application. 

A, Aldred, in view of Raynak disclose the claimed limitations 

Claim I discloses a first application launching a second application, the launch 
including passing of event and command port numbers are passed to the second 
application and wherein the port numbers are stored in a memory. Claim i does not 
disclose establishing connections utilizing the port numbers as part of the launching 
(this functionality is seen in the dependent claims) or configuring the ports. 

As discussed by Applicant, Aldred is concerned with the establishment of 
channels between two applications, one operating at a source node and the second 
operating at a destination node [column i «lines 11-13 and 6i-65»]. Aldred discloses 
that a first application may invoke a second application utilizing a "launch_app" 
function [column 29 «lines i9-20»]. This "launch_app" function consists of several 
variables, including parameters consisting of a user-specified string that is given to 
the second application as part of the launching process [column 36 «lines 2i-44»]. As 
set forth in the final Office action, filed 10.3.2005, the functionality of passing port 
numbers as the parameters within the "launch_app" function was not expressly 
disclosed in Aldred, but it is obvious based on Aldred's disclosure that a channel (a 
network connection established between a first application and a second application) 
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is always defined by the first, sending application [column 6 «lines 20-24»]. Channels 
are defined by their receiving and sending ports [column 6 «lines 24-26»]. 

Raynak further teaches this feature. Raynak discloses two applications with 
one application launching a second application, passing the second application various 
parameters, including as port information, that allows the second application to 
communicate over a network [column 6 «lines 36-65»]. The passing of the port 
information to the launched application is necessary in order for the launched 
application to properly utilize the established network connection. While not 
precisely the same, this functionality is similar to Aldred's first and second 
applications. Thus, it would have been obvious to one of ordinary skill in the art to 
utilize the parameters of Aldred*s launch_app function to pass Aldred's command and 
event port numbers from a launching application to a launched application, as taught 
by Raynak. 

B. Applicant's arguments are unrelated to the claimed limitations 

Applicant makes several arguments but they are unrelated to the limitation of 
passing port information between a first and second application. In support of these 
arguments, Applicant discusses several features of Aldred, such as Aldred's support 
system software, call managers and the need for launched applications to register to 
identify itself to the system. Applicant discusses these features in the context of 
Aldred establishing channels between applications or configuring port numbers after 
an application has launched. However, establishing channels or configuring ports 
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have no bearing on the limitation of whether port numbers are passed to an 
appUcation at the time it is launched. 

Indeed, according to Applicant's claim i and Applicant's specification, when - 
port numbers are passed to the launched application, the launched application merely 
stores the numbers. There are no limitations with regards to establishing 
communications or even configuring the ports. Thus, the prior art references need 
only teach passing of port numbers between one application to a second application, 
not establishing communications or configuring the ports as part of the launching 
process. It should be clearly noted that Applicant's claim i does not at all discuss 
configuring ports or even establishing a connection to said port, but merely that the 
ports are passed along to the launched application - no other action is taken. 

It seems that it is Applicant's position that Aldred teaches that port 
information is only submitted upon establishment of connections or configuring of 
ports. That is, Applicant asserts that Aldred cannot teach passing port numbers to a 
launched application simply because Aldred discloses mechanisms for passing port 
information after an application has been launched. However, Aldred does not 
support this supposition. Aldred merely discloses several functions that enable 
specifying port information but in no way does he limit other times when the port 
information can be submitted between the applications. 

In regards to Applicant's arguments. Applicant's first argues that the purpose 
of Aldred's support system, to establish and configure communication channels, 
supports the assertion that applications need not pass port numbers when launching. 
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However, it is unclear why this asserted purpose of Aldred's support system 
necessitates the conclusion that a launching application cannot pass port numbers to a 
launched application. Applicant's argument seems to imply that because the support 
system is responsible for establishing and configuring ports, applications do not need 
to pass port numbers when launching a second application. However, establishing and 
configuring ports after an application has been launched is not at all related to 
whether port information may be passed from a launching application to a launched 
application. 

Applicant next addresses the register functionality whereby all of Aldred's 
launched applications must register with the support system to fully identify itself 
. and to properly communicate. The fact that a launched application must register to 
identify itself also does not necessitate the conclusion that a first application need not 
pass port information to a second application upon launching. Applicant places great 
emphasis throughout the Brief on the fact that a launched application must first 
register before it is able to communicate over the system. Contrary to Applicant's 
characterizations, Aldred does not suggest or teach a that because a launched 
application must register to identify itself to communicate over the network, that port 
information cannot be passed to an application when it is launched. 

Aldred discloses a "launch_app" function with parameters that enable a 
launching application to supplied user defined parameters to a launched application, 
but did not expressly teach port information as part of these parameters. Raynak was 
relied upon to expressly teach the limitation of passing port information to a launched 
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application. Applicant's arguments seem to imply that the port information is only 
received at a launched application after it has been launched since Aldred's launched 
application's communications are limited until registering itself. However, nothing in 
Aldred supports this argument. 

Applicant's argument that "ports. ..are only configured after an application has 
registered with the support system" (Appeal Brief , pg. 7, 51) is particularly indicative. 
First, Applicant bases this assertion on Aldred's disclosure of a limited use handle that 
is only valid in restricted circumstances until the launched application has registered. 
Nothing in this citation suggests that ports are configured after an application has 
registered. Second, whether or not Aldred teaches that ports are configured after 
registering is entirely unrelated to the limitation of whether port information may be 
passed as part of launching the application. According to Applicant's claim i, the 
launched application merely need to store the port information. It is in the dependent 
claims, such as claim z, where Applicant discloses establishing connections between 
the applications. Launching of an application does not necessitate establishing of 
connections or configuring of ports. 

Next, Applicant focuses on the difference between establishing the channel 
and defining the channel characteristics. Applicant asserts that Aldred merely 
discloses defining the channel characteristics, not establishing the channel. See 
Appeal Brief , pg. 8, 53. This argument is unrelated to whether or not port numbers are 
passed to a launched application. Indeed, the fact that a launching application is 
responsible for defining the channel characteristics (including the ports) supports the 
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idea that the port numbers must be passed to the launched apphcation. That is, the 
launching application must notify other applications of the channel characteristics, 
such as which ports to use, so that these other applications may use the channel to 
communicate with the launching application. Whether or not the launching 
establishes the channel itself, as argued by Applicant, is unrelated to whether or not 
the channel characteristics are passed as part of launching another application. As 
discussed earlier and as supported by Applicant's own dependent claims, launching of 
an application is not the same as establishing communications with the application. 

Thus, Applicant's focuses on Aldred's features, such as the establishment of 
channels or configuration of ports, that happen after an application has already been 
launched. No where in Aldred is there any teaching that port numbers are only 
submitted after an application has been launched. Aldred merely discloses several 
features that allow applications to pass port numbers as part of establishing 
communications but Aldred does not limit other tinies, such as during the launching 
of a second application, when these port numbers may be passed. Raynak in fact 
discloses a benefit of submitted the port information at the time an application is 
launched. 

C. Aldred does not teach away from an application passing port numbers to a 
second application 

Applicant argues in substance that Aldred teaches away from passing port 
numbers as parameters within the "launch_app" function. Applicant argues that 
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Aldred already includes a mechanism to initiate and configure ports and channel 
between application because an application must first register with a call manager and 
joining a share set before initiating or configuring channels. Like Applicant's previous 
arguments, this argument shifts the focus away from the limitation set forth in the 
claim - that port numbers are passed to a second application as part of the launching 
process. Applicant's arguments imply that the configuring or initiating of channels is 
part of the launching process but this is clearly not true. Applicant's dependent 
claims, such as claims 2 and 3, disclose that the launched application establishes a 
connection after it has been launched, not as part of the launching process. 

Further, Applicant argues that modification of Aldred with Raynak's teachings 
are improper. Applicant again points to the features of Aldred related towards 
initiating and configuring channels and ports as teaching away from Raynak's 
inclusion of port information as parameters for launching a second application. 
However as discussed above, Aldred's sharing set and call manager are entirely 
unrelated towards the launching of a second application. The mere fact that they may 
aid an application in initiating and configuring a channel does not teach away from 
passing port numbers as part of launching an application, which is taught by Raynak. 
Thus, what is being modified is Aldred's "launch_app" function, and specifically, the 
parameters (user specified string) that enable a launching application to communicate 
with the launched application. Raynak discloses passing port information as part of 
launching a second application in order for the second application to be aware of 
which port to utilize if he desires to communicate over the network. This 
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functionality is entirely consistent with Aldred's goals of establishing 
communications for applications. 

Applicant also contends that Aldred has a specific set of APIs allowing 
applications to setup command and event ports, including specifying numbers. 
However, Applicant's argument that port numbers are not passed as part of launching 
an application does not follow simply because Aldred discloses a set of commands to 
configure ports. Having a different set of commands to configure ports does not teach 
away from passing port numbers to a launched application. Aldred does not expressly 
state that port numbers are only passed between applications utilizing the specific set 
of APIs, Thus, Aldred cannot teach away from passing the port numbers as part of 
the launching process. 

Next, Applicant argues that modifying Aldred to include passing an event port 
number and a command port number to an application as part of launching that 
application changes the principle of operation of Aldred's system. This argument is 
based on Applicant's characterization of Aldred's call managers and support system 
that initiate and configure communications between applications. As discussed above, 
even if Applicant's characterization is accurate, the features discussed are entirely 
separate from the limitation of passing port numbers as part of the launching process. 
Initiating and configuring communications between applications is not the same 
feature as a first application launching a second application. 

Finally, Applicant contends that there is no proper motivation for combining 
the teachings of Aldred and Raynak. There are three possible sources for a motivation 
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to combine references: the nature of the problem to be solved, the teachings of the 
prior art, and the knowledge of persons of ordinary skill in the art," In re Rouffet, 149 
F.3d 1350, 1357, 47 USPQ2d 1453, HSy'SS (Fed. Cir. 1998). Here, the motivation to 
combine comes from the nature of the problem to be solved. Both Aldred and Raynak 
deal with establishing communications for a newly launched application. Aldred 
provides a mechanism in his "launch_app" function and its parameters that would 
enable an application to pass various parameters to a launched application. Raynak 
supplements Aldred by explicitly describing a means by which port information is 
passed from one launching application to a second launched application. The passing 
of the port information enables the launched application to properly communicate 
over a network [see Raynak, column 6 «lines 50'54»]. Thus the reason for modifying 
Aldred with Raynak is to enable a launched application to be aware of the necessary 
port information in order to communicate over a network when it is launched. 

II. Claims s and 16 

Aldred discloses that applications communicate with one another through channels 
[column 6 «lines i6-20»]. These channels have a sending port and a receiving port [column 6 
«lines 24-26»]. There are three types of ports: event, command and null. The purpose of 
event ports are for only generating an event when data is available or required [column 7 
«lines 45'46»]. The purpose of null ports is reserved only for ports that are unable to supply 
data [column 7 «lines 47'50»]. The purpose of the command port, on the other hand, is for 
allowing applications to receive and supply data to other applications [column 7 «lines 46- 
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47»]. Thus, while not expressly stated, it would be clear that the majority of data that is 
passed between applications is passed through the command port of a channel. 

Applicant argues that Aldred does not disclose passing a function reference value 
through the command port connection. Applicant's specification provides no clear guidance 
for interpreting a function reference value or that such a value is passed through a command 
port (see §112 rejection in section 9). Instead, the specification describes a function reference 
number that simply is used to identify a function. Similarly, Aldred discusses utilizing a 
reference identifier that identifies certain API calls. These calls are analogous to functions, 
Aldred discusses that these calls result in applications communicating information, such as 
event information and the reference identifiers, between each other [column 24 «lines 39- 
6i»]. ' . 

Since Aldred discloses utilizing command ports only for the passing back of data 
between applications, it would have been obvious to one of ordinary skill in the art that these 
reference identifiers, that refer to the calls, would be passed through the command port 
(while the event information is passed through the event port). 

Applicant again references the support system suggesting that the reference 
identifiers are passed between the support system and an application. However, nothing in 
the cited section of Aldred even mentions a support system [column 24 «lines 39-6i»]. The 
cited section instead discusses the communications that occur between applications during an 
API call, including the communication of event information and reference identifiers. 


III. Claims 6 and 17 
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As discussed in claims 5 and 16, Aldred discloses utilizing command ports for 
receiving and supplying data between applications. Aldred clearly establishes that the event 
port is merely for generating an event when data is available or required. Any data that is 
submitted between applications is actually sent through the command port. Aldred clearly 
regards parameters of a command call as data [see, for example, column 13 «lines 58-6o» | 
column 36 «lines 23-44»]. That is, these parameters clearly represent data values such as user 
specified strings or application handles, Aldred also discloses that these parameters are 
transmitted between applications [column 12 «lines 40-64»]. Thus, it stands to reason that 
since the function parameters are data values, the parameters are passed between applications 
and Aldred utilizes command ports to pass data, that the function parameters are passed only 
through the command ports. 

IV. Claims 7 and 18 

Applicant argues that Jalili does not teach passing a value of a memory location for 
storing results of a function. It should be noted that the claim fails to specify who passes the 
value and who receives the value of the memory location. Jalili discloses that the server may 
pass memory locations (in the form of pointers): "the server passes the ITP (the location of 
this space) to the entry function where the ITP is stored in the entry function argument" 
[column 7 «lines 3o-33»]. Additionally, Jalili discloses; "The function is passed the value in 
the state field 288 which points to the pre-allocated space where the arguments to the 
function reside" [column 9 «lines 35-37»]. Jalili thus discloses the passing of a value of a 
memory location for storing results of a function. 
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(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the 
Related Appeals and Interferences section of this examiner's answer. 

For the above reasons, it is believed that the rejections should be sustained. 
Respectfully submitted, 
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